System for and method of effecting an electronic transaction

ABSTRACT

A system for and method of performing a transaction between a consumer ( 105 ) and a business entity ( 110 ). The method comprising the acts of priding transaction data from a submitter ( 105 ) to a transaction facilitator ( 120 ), generating a token ( 130 ) that identifies the transaction data, storing the transaction data and the token at the transaction facilitator ( 120 ), providing the token to the submitter ( 105 ), returning the token ( 130 ) to the transaction facilitator, obtaining the stored transaction data identified by the token, and using at least a portion of the obtained transaction data to implement the transaction.

RELATED APPLICATIONS

This patent application is a national stage filing under 35 U.S.C. 371of International Application No. PCT/US01/11930 filed on Apr. 12, 2001,which claims the benefit of U.S. Provisional Application No. 60/204,270filed on May 15, 2000.

BACKGROUND OF THE INVENTION

The invention relates to a system for and method of effecting anelectronic transaction, and particularly to a system for and method ofeffecting an electronic transaction between a first entity and a secondentity utilizing a third entity as a transaction facilitator.

When a consumer performs a debit transaction at a merchant's or serviceprovider's (collectively referred to as “business entity”)brick-and-mortar place of business, the consumer typically providesdebit financial information and a debit password. The financialinformation, which includes account data, may be stored on a magneticstrip card that is scanned by a magnetic card reader (e.g., apoint-of-sale device). Upon scanning the card, the consumer enters adebit password into the card reader. The information is then transmittedto a third party to perform the debit transaction. When a debittransaction is performed over the Internet, the debit information issupplied by the consumer directly to the merchant over unsecured lines,thus placing the consumer at more risk than with a conventional debittransaction.

In certain transactions, the business entity may not receive payment atthe same time that the goods are shipped or that the services areperformed. This often occurs where the purchase involves a payment planrequiring recurring payments. Nevertheless, the financial information isstill requested prior to performing the services or prior to shippingthe goods. The consumer may have a natural reluctance to provide thisinformation to be used in an ongoing manner to effect recurringpayments.

In other transactions, the business entity may require additionalinformation not typically included in conventional debit transactions.For example, if the consumer is purchasing alcohol, the business entitymay be obligated to confirm that the consumer is of legal drinking age.In other transactions, the business entity may be required to determinethe consumer's place of residence. For example, the business entity mayhave to tax the consumer based on the consumer's place of legaldomicile. The above determinations, and others like them, are difficultto determine in the context of an Internet transaction.

SUMMARY OF THE INVENTION

It would be beneficial to provide a secure system allowing a consumer tosubmit transaction information as part of a transaction while preventingthe business entity from receiving some or all of the transactioninformation. In addition, it would be beneficial for the business entityto be able to verify that the consumer meets specific requirements or touse consumer specific data for certain aspects of the transaction.

Accordingly, the invention provides a third party or transactionfacilitator that stores the consumer's transaction information on behalfof the consumer and provides an electronic or software based “token” tothe business entity. The business entity may later submit the token(e.g., when the services are rendered or when the goods are shipped) toreceive payment for goods provided or services rendered. In othertransactions, the consumer may “pre-register” with the third party andreceive a token. The token may then be provided to the business entity,who submits the token to receive payment. In other transactions, a partyacting on behalf of the business entity may receive the token, and latersubmit the token to receive payment on behalf of the business entity.The token may include restrictions on how the token may be used. Forexample, the token may have a date restriction limiting when the tokenmay be submitted and/or may have an amount restriction or limit.

In addition, the third party may review the consumer providedtransaction information and provide specific consumer information to thebusiness entity. For example, the third party may inform the businessentity whether the consumer meets specific requirements (e.g., is acertain age). Alternatively, the consumer may provide the businessentity information that is required to complete the transaction (e.g.,the state that the consumer is legally domiciled in for calculatingtaxes).

In one embodiment, the invention provides a method of performing atransaction between a consumer and a business entity. The methodincludes the acts of providing transaction data from a submitter to atransaction facilitator, generating a token that identifies thetransaction data, storing the transaction data and the token at thetransaction facilitator, providing the token to the submitter, returningthe token to the transaction facilitator, obtaining the storedtransaction data identified by the token, and using at least a portionof the obtained transaction data to implement the transaction.

In another embodiment, the invention includes the act of providingencrypted data to a consumer. The encrypted data includes encryptedaccount specific data and encrypted consumer specific data. Theinvention further includes the acts of transmitting the encrypted datato a transaction facilitator as part of a transaction, and decryptingthe encrypted data to produce decrypted data. The decrypted dataincludes decrypted account specific data and decrypted consumer specificdata. The invention further includes the act of using the decryptedconsumer specific data to complete the transaction.

Other features and advantages of the invention will become apparent tothose skilled in the art upon review of the following detaileddescription, claims, and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of a system embodying theinvention.

FIG. 2 is a schematic representation of a consumer terminal used in thesystem shown in FIG. 1.

FIG. 3 is a schematic representation of a business entity terminal usedin the system shown in FIG. 1.

FIG. 4 is a schematic representation of a payment administrator terminalused in the system shown in FIG. 1.

FIG. 5 is a schematic representation of an electronic financialtransaction system used in the system shown in FIG. 1.

DETAILED DESCRIPTION

Before any embodiments of the invention are explained in full detail, itis to be understood that the invention is not limited in its applicationto the details of construction and the arrangement of components setforth in the following description or illustrated in the followingdrawings. The invention is capable of other embodiments and of beingpracticed or of being carried out in various ways. Also, it is to beunderstood that the phraseology and terminology used herein is for thepurpose of description and should not be regarded as limiting. The useof “including” and “comprising” and variations thereof herein is meantto encompass the items listed thereafter and equivalents thereof as wellas additional items.

One embodiment of a system 100 for performing a transaction between aconsumer and a business entity of the invention is shown in FIG. 1. Asused within this application, the consumer is any first party payingcurrency to a second party for the purchase or use of goods, services,or property. The business entity is any second party receiving paymentfrom a first party for the purchase or use of goods, services orproperty. The transaction may be a purchase of goods, services orproperty, a purchase of the temporary right to the use of goods, orproperty, or the purchase of an expectation to receive goods, servicesor property. For the purposes of simplifying the detailed description,the transaction will be described as a simple purchase of goods orservices. Furthermore, if the business entity is receiving the currencyor funds at the time the transaction is being entered into, then thattransaction is referred to as an “immediate transaction.” Alternatively,if the consumer and business entity agree that a transfer of currencywill occur at a later time, then the original agreement is a “set-uptransaction” and the later payment is a “subsequent transaction.” Forsome transactions, the later payment may be a repetitive payment (e.g.,a monthly payment). This type of subsequent transaction is referred toas a “recurring transaction.”

As shown in FIG. 1, the system 100 generally includes a consumerterminal 105, a business-entity terminal 110, a payment-administratorterminal 115, an electronic financial transaction system 120, a currencyexchange network 125, an issuing financial institution (FI) 130, anacquiring financial institution (FI) 135, and a network 140. As will bebecome apparent below, FIG. 1 shows only one preferred embodiment of thesystem for performing a financial transaction.

As shown in FIGS. 1 and 2, the financial transaction system 100 includesa consumer terminal 105. The consumer terminal 105 generally includes aprocessor 150, one or more memory units (not shown), one or more dataentry apparatus 160, and one or more data output apparatus 165. Theprocessor 150 interprets and executes instructions stored as one or moresoftware modules 167. The data entry apparatus 160 provides an interfacefor receiving data provided by the consumer. The data entry apparatus160 may be a keyboard, a touch screen, a magnetic-disc drive, a CD-ROMdrive, a DVD-ROM drive, a scanner, a communication system for receivingdata from another device, etc. The data output apparatus 165 provides aninterface for communicating data from the consumer terminal 105 to theconsumer. The data-output apparatus 165 may be a visual display device(e.g., a monitor), a hard-copy device (e.g., a printer), a magnetic discdrive, a CD-ROM write drive, a DVD-ROM write drive, an audio speaker, acommunication system for transmitting data to another device, etc.

The software modules 167 include an operating system 170, acommunications module 175, a browser 180, and other applications 185.The operating system 170 includes software that controls the allocationand use of hardware resources of the consumer terminal 105. Thecommunications module 175 includes hardware and associated software forproviding communications between the consumer terminal 105 and thenetwork 140. The browser 180 includes software allowing the consumer toview the content provided via the network 140. The other applications185 include applications for controlling the data entry apparatus 160and the data output apparatus 165. Other functions performed by theconsumer terminal 105 will become apparent in the description below.

Although only one consumer terminal 105 is shown, the system 100 mayinclude multiple consumer terminals 105. A suitable consumer terminal105 is any personal computer having a Windows brand operating system anda Netscape brand browser. Other suitable consumer terminals 105 includekiosks, personal data assistants, hand-held computers, laptop computers,videophones, Internet appliances, and similar devices. Additionally andas required in other financial transaction systems, other devices may beused in place of the consumer terminal 105. For example, in oneembodiment of the invention, a telephone allowing the consumer tocommunicate with a payment administrator may be used in place of theconsumer terminal 105.

As shown in FIGS. 1 and 3, the system 100 further includes a businessentity terminal 110. The business terminal 110 includes one or moreprocessors 200 and one or more memory units (not shown) that togetherprovide a platform for hosting a web site at which consumers canpurchase goods or services. The processor 200 interprets and executesinstructions stored as one or more software modules 205.

The software modules 205 include an operating system 210, acommunications module 215, a web content server 220, site content 225,and administration control 230. The operating system 210 includessoftware that controls the allocation and usage of hardware resources ofthe business entity terminal 110. The communications module 215 includeshardware and associated software for providing communications betweenthe business entity terminal 110 and the network 140. The web contentserver 220 generates the business-entity web site for selling goods orservices with content provided by the site content 225. Theadministration control module 230 provides administration support (e.g.,billing or account services) for the business entity terminal 110. Inaddition, the memory units may further include one or more databases 207for storing data. Other functions performed by the business entityterminal 110 will become apparent in the description below.

Although only one business entity terminal 110 is shown, the system 100may include multiple business-entity terminals. A suitable businessentity terminal 110 for the invention is a Sun Enterprise 420R brandserver with a Solaris brand operating system and an Apache brand webserver. Other business entity terminals may be used and, similar to theconsumer terminal 105, other devices may be used in place of thebusiness entity terminal. For example, in some embodiments of theinvention, any business entity operated device for receiving a token(discussed below) may be used in place of the business entity terminal.

As shown in FIGS. 1 and 4, the system 100 further includes a paymentadministrator terminal 115. The payment administrator terminal 115includes one or more processors 250 and one or more memory units (notshown). The payment administrator terminal 115 acquires transaction datafrom the consumer (e.g., the consumer terminal 105) or the businessentity (e.g., the business entity terminal 110), and communicates withthe electronic financial transaction system 120 for completing atransaction. In some embodiments of the invention, the paymentadministrator terminal 115 communicates with the electronic financialtransaction system 120 on behalf of the consumer. In other embodimentsof the invention, the payment administrator terminal 115 communicateswith the electronic financial transaction system 120 on behalf of thebusiness entity. In yet other embodiments of the invention, the paymentadministrator terminal 115 communicates with the electronic financialtransaction system 120 on behalf of both the consumer and the businessentity. In even yet other embodiments of the invention, the paymentadministrator terminal 115 is not part of the transaction (e.g., eitherthe consumer or the business entity directly communicates with theelectronic financial system 120). Unless specified otherwise, thepayment administrator terminal 115 communicates with the electronicfinancial system 120 on behalf of the business entity.

Referring to FIG. 4, the processor 250 interprets and executesinstructions stored as one or more software modules 255. The softwaremodules 255 include an operating system 260, a communications module265, a web content server 270, site content 275, and administrationcontrol 280. The operating system 260 includes software that controlsthe allocation and usage of hardware resources of the paymentadministrator terminal 115. The communications module 265 includeshardware and associated software for providing communications betweenthe payment administrator terminal 115 and the network 140. The webcontent server 270 generates a payment administration web site foracquiring transaction data from the consumer terminal 105 on behalf ofthe administrator with content provided by the content site 275. Theadministration control module 280 provides administration support (e.g.,billing or account services) for the payment administrator terminal 115.In addition, the memory units may further include one or more databases257 for storing data. Other functions performed by the paymentadministrator terminal 115 will become apparent in the descriptionbelow.

A suitable payment administrator terminal 115 for the invention is a SunEnterprise 420R brand server with a Solaris brand operating system andan Apache brand web server. Other payment administrator terminals 115may be used and, similar to the business entity terminal 110, otherdevices may be used in place of the payment administrator terminal 115.An example payment administrator that provides the services of thepayment administrator terminal 115 is the Electronic Payment Exchange(EPX) brand payment administrator.

As shown in FIGS. 1 and 5, the system 100 includes an electronicfinancial transaction system 120. In general, the electronic financialtransaction system 120 acts as a transaction facilitator. The electronicfinancial transactions system 120 receives transaction data (discussedbelow) from a submitter (e.g., the consumer terminal 105, the businessentity terminal 110, payment administrator terminal 115); generates atoken (discussed below) that identifies the transaction data; stores thetransaction data and the token; provides the token to the submitter,receives the token from the submitter, obtains the stored transactiondata identified by the token; and uses at least a portion of theobtained transaction data to implement a financial transaction(discussed below).

As shown in FIG. 5, the electronic financial transaction system 120generally includes a main processor 300, a currency exchangecommunications processor 305, a primary message control 310, a log 315,and a financial data storage system 320. The main processor 300interprets and executes instructions stored as one or more softwaremodules for controlling the flow of data within the electronic financialtransaction system 120. The currency exchange communications processor305 interprets and executes instructions for controlling communicationsbetween the financial information storage system 320 and the currencyexchange network 125. The primary message control 310 interprets andexecutes instructions for preparing requests (discussed below) to betransmitted to the issuing FI 130 and/or the acquiring FI 135 via thecurrency exchange network 125. The log database 315 stores a record ofeach transaction implemented. The transaction may be a request forinformation, a request to debit or credit a financial account or arequest to add funds to a financial account. For the embodiment shown,the financial data storage system 320 generates a token that identifiesthe transaction data, stores the transaction data and the token, andobtains the stored transaction data identified by a returned token. Ofcourse, the number of processors and the number of databases shown mayvary.

As shown in FIG. 5, the financial data storage system 320 includes acollector processor 350, a rules engine 353, a security processor 355, adecryption processor 360, a database engine 365, a transaction datastorage database 370, and a business database 375. The collectorprocessor 350 interprets and executes instructions stored as one or moresoftware modules for communicating with the main processor 300, forverifying the transaction is one that can be processed by the financialdata storage system 320, and for translating the data, if necessary, toa format capable of being used by the financial data storage system 320.The rules engine 353 interprets and executes instructions stored as oneor more software modules for obtaining and analyzing transaction databased on transaction parameters (discussed below). The transactionparameters may have been previously set or may have been transmitted aspart of the current transaction being processed. The rules engine 353also interacts with the database engine 365 to obtain data from thedatabases 370 and 375. The security processor 355 interprets andexecutes instructions stored as one or more software modules forreceiving data from the rules engine 355, for formatting the data fortransmission to the decryption processor 360, and for obtaining datafrom the decryption processor 360. The decryption processor 360interprets and executes instructions stored as one or more softwaremodules for decrypting received encrypted data. For the embodimentshown, the decryption processor 360 is a Network Security Processor(NSP) manufactured by the Atalla Security Group of Compaq Computers. Thedecryption processor 360 includes one or more processors and one or morememory modules. The database engine 365 interprets and executesinstructions stored as one or more software modules in memory forcontrolling the reading and writing of data to the transaction datastorage database 370 and the business storage database 375.

The transaction data storage database 370 stores transaction data and atoken assigned to the transaction data. The transaction data identifiedby the token is recalled in subsequent or latter transactions. Inaddition, the stored transaction data may be updated from time-to-time(e.g., when a subsequent or recurring transaction is performed as isdiscussed below).

The business database 375 stores security keys used by the decryptionprocessor 360. The security keys are identified by an encrypted dataidentifier (discussed below), which has been previously provided to theelectronic financial system 120 by an encrypted data issuer (e.g., theissuing bank). For example and in one embodiment of the invention, theissuing FI 130 issues encrypted financial data stored on a SAFE DEBITbrand CD-ROM to the consumer. The encrypted financial data has acorresponding security key allowing for the encrypted financial data tobe decrypted. The security key is provided from the issuing FI 130 tothe operator of the electronic financial system 120 and is stored in thebusiness database 375. In order to recall the proper key, the CD-ROMincludes a CD-ROM identifier (e.g., a CD-ROM number) that associates theencrypted data on the CD-ROM to the security key. The encrypted dataidentifier (e.g., the CD-ROM identifier) is also stored at the businessdatabase 375. Thus, when the financial data storage system 320 receivesencrypted data and an associated encrypted data identifier, thefinancial data storage system may recall the proper key. As will bediscussed below, the encrypted data may be stored on other computerreadable media. Additionally, for some embodiments of the invention, theencrypted data identifier may not be required (e.g., when thetransaction does not include any encrypted data).

The business database 375 further contains transaction parameters notspecific to the pending transaction. For example, the issuing FI 130 mayrequest that all transactions performed with the issuing FI 130 as theissuing FI of record include a specific parameter. For a specificexample, the issuing FI 130 may require that only transactions less than$10,000 be facilitated by the electronic financial transaction system120. Other parties to the transaction (e.g., the acquiring FI 135, thepayment administrator 115, etc.) may require non-transaction specifictransaction parameters included in the business database 375.

One skilled in the art would realize that the functions of eachprocessor 350, 353, 355, 360 and 365 may be divided among any number ofprocessors. For example, the functions of the database engine 365 may becombined with the rules engine 353. Alternatively, the database engine365 may be further broken into two separate database engines: a firstdatabase engine for the business database 375 and a second databaseengine for the financial data storage database 370. Similarly, oneskilled in the art would realize that the databases 370 and 375 may becombined into one database or broken into further multiple databases.Even further yet, the functions performed by the financial data storagesystem 320 may be performed by other processors of the electronicfinancial transaction system (e.g., main processor 300).

The financial data storage system 320 further includes one or moreprocessors and one or more databases for ancillary functions. Thefinancial data storage system 320 further includes a databaseconfiguration command and control terminal 380, a database housekeepingprocessor 385, an action management processor 390, a trace/auditprocessor 395, an event management processor 400, a system database 410,a trace log 415 and an event log 420. The database housekeepingprocessor interprets and executes instructions stored as one or moresoftware modules for maintaining the business database 375 and thefinancial data storage database 370. For example, if the financial datastorage database 370 is too large, then the database housekeepingprocessor 385 archives or erases old or obsolete data. The eventmanagement processor 400 interprets and executes instructions stored asone or more software modules for recording errors in the event log 420when errors arise. The trace/audit processor 395 interprets and executesinstructions stored as one or more software modules for tracing theoccurrence of certain events and for storing the events in the trace log415. The trace log 415 informs an operator how the financial datastorage system 320 is performing (e.g., is the system at capacity or area large number of errors occurring?). The action management processor390 interprets and executes instructions for determining the severity ofan error. For example, the action management processor 390 determineswhether a failure is a minor failure, a serious failure or a fundamentalfailure. Based on the type of failure, the action management processor390 may allow the transaction to continue while noting the failure, maystop the transaction from occurring, or may “shut-down” the financialdata storage system 320. The database configuration command and controlterminal 380 allows an operator to configure and control the financialdata storage system 320. Of course, the terminal 380 may be one or moreoperation consoles. The system database 410 defines or configures thehardware of the financial data storage system 320. Of course, otherancillary functions can be added, or one or more ancillary may removedor combined with other ancillary functions.

An example electronic financial transaction system 120 is the PAYMENTWAREHOUSE SYSTEM brand financial transaction system maintained by eFundsCorporation. The PAYMENT WAREHOUSE SYSTEM brand financial transactionsystem includes a Tandem Himalaya machine sold by Compaq and an A10000ENSP manufactured by the Atalla Security Group of Compaq Computers. Invarious embodiments of the invention, the functions of the mainprocessor 300, the currency exchange processor 305 and the financialinformation storage system 320 may be combined into one processor.Similarly, the log database 315 and the transaction data storagedatabase 370 may be combined into one database. Even further, thefunctions of the Atalla A10000E system may be performed by the otherprocessors shown. Even further yet, the functions performed by thefinancial data storage system 320 may be performed by other processorsof the electronic financial transaction system 120 (e.g., main processor300).

As shown in FIG. 1, the system 100 includes a currency exchange network125. The currency exchange network 125 is a network that providestransaction communications between the electronic financial transactionsystem 120, the issuing FI 130 and the acquiring FI 135. Thecommunication may be a request to remove or add funds in an account atthe issuing FI 130 or the acquiring FI 135. Alternatively, thecommunication may be for a request for information from either theissuing FI 130 and/or the acquiring FI 135. An example of a currencyexchange network 125 is an electronic funds transfer (EFT) network suchas the Legacy exchange network (e.g., TYME, STAR, NYCE, etc.).

The issuing FI 130 is a financial institution that maintains a financialaccount on behalf of the consumer. The consumer's financial account maybe a debit account, a credit account, a money market account, or anyother type of demand/deposit account. The acquiring FI 135 is afinancial institution that maintains a financial account on behalf ofthe business entity. The business entity's financial account may be adebit account, a credit account, a money market account, or any othertype of demand/deposit account. In some embodiments of the invention,the payment administrator 115 may communicate with the acquiring FI 135.In other embodiments of the invention where the payment administratorterminal 115 acts on behalf of the business entity, the acquiring FI 135may be the payment administrator terminal's FI.

The network 140 is a packet-switch-based network based on protocols, andmay include wire and/or wireless connections. A network 140 suitable foruse in the invention is the Internet. In other embodiments (not shown),the network 140 may be any communications network and may includemultiple different types of communication networks.

Having described the basic architecture of the system 100, differentembodiments of operation will be explained below. For the embodimentshown in the figures, the consumer accesses the network 140 (e.g., theInternet) via the consumer terminal 105. The consumer navigates theInternet by seamlessly linking from web page to web page as is wellknown in the art. At some point in time, the consumer accesses thebusiness entity web site provided by the business terminal 110. Theconsumer navigates through the business entity web site to view thecontent of the site 225 as is well known in the art. For example, theweb site may be a web site for purchasing goods or services and theconsumer can view the goods or services that are for sale.

When the consumer requests to enter into a transaction, the consumer isseamlessly linked to a web page provided by the payment administratorterminal 115. The web pages provided by the payment administratorterminal 115 may have a style substantially similar to the businessentity web site. A similar web page design provides an appearance to theconsumer that the consumer is still within the business entity web site.Alternatively, the web page may identify the payment administratorinforming the consumer they are at a different web server 220. In analternative embodiment, when the consumer requests to purchase a good orservice, the consumer remains at the business entity web site. In stillanother embodiment, the payment administrator terminal 115 may providethe business entity's web site on behalf of the business entity. Inother embodiments, the consumer may communicate with a paymentadministrator by communication networks other than the Internet, andthat communication is prior to communicating with the business entity.Variations of the embodiments described above are also possible.

In the embodiment shown in the figures, the payment administratorterminal 115 obtains transaction data via the Internet on behalf of thebusiness entity. The transaction data may include encrypted data, atleast one encrypted data identifier, a consumer-supplied password, abusiness entity identifier (e.g., a business entity name), a tracenumber, a transaction date, a transaction time, acquiring FI data,transaction parameters, and other data as specified by the issuing FI130. For example, the payment administrator terminal 115 may transmitsoftware to the consumer terminal 105 that interacts with the consumerterminal 105 to acquire the transaction data, including the encrypteddata. The encrypted data is data stored on a computer readable media andinclude encrypted consumer specific data and encrypted financial accountdata. Example consumer specific data include a consumer name, a consumerpostal address, a consumer residency or legal domicile (if differentthan the address), at least one consumer password, a date of birth ofthe consumer, an age of the consumer (if the date of birth is notprovided), an email address, a citizenship of the consumer, etc. Examplefinancial account data include data relating to the consumer's accountat the issuing FI (e.g., a routing/transit number for the FI, an accountnumber at the issuing FI, an account password for performing an actionwithin the account, etc.). Additional data may be included as part ofthe encrypted data. The computer readable media may be a CD-ROM, aDVD-ROM, a magnetic storage media (e.g., a magnetic-disc), a memory unitof the consumer terminal (e.g., a hard-drive of the PC), etc. In theembodiment described herein, the encrypted data is stored on a SAFEDEBIT brand CD-ROM. The encrypted data identifier allows the electronicfinancial transaction system identify who issued the encrypted data andidentifies the encrypted data. For example, it may identify the issuingFI that issued the CD-ROM and identify the CD-ROM.

The consumer-supplied password verifies that the correct consumer issubmitting the encrypted data. As will be discussed below, when theencrypted data is decrypted, the decrypted password may be compared tothe consumer-supplied password for verification. The business entityidentifier identifies who is receiving the funds.

The trace number allows the payment administrator terminal 115 toidentify the transaction for later reconciliation. For example, theelectronic financial transaction system 120 may provide an outcomeresponse to the payment administrator terminal 115 that also includesthe trace number. The payment administrator terminal 115 matches theresponse with the transaction by the trace number. The transaction dateand time are also used for further identifying the transaction.

The acquiring FI data identify the account receiving the funds. Theacquiring FI data may include a routing/transit number for the acquiringFI and an account number within the acquiring FI. The transactionparameters are the agreed upon terms of the transaction as establishedbetween the business entity and the consumer. Example transactionparameters include amount, type of transaction (e.g., immediate, set-up,subsequent, or recurring), date restrictions (if setting-up for asubsequent transaction), recurrence restrictions (if setting-up for arecurring transaction), and other agreed upon terms. The transactiondata may be obtained from the consumer terminal 105, the business entityterminal 110, a combination of both terminals 105 and 110, and/ororiginated at the administrator terminal 115. Of course, additionaltransaction data may be provided and not all of the financialtransaction data may be required for all transactions.

Upon receipt of the transaction data, the payment administrator terminal115 collects the data, organizes the data and forwards the data to theelectronic financial transaction system 120. When the electronicfinancial transaction system 120 receives the transaction data, thesystem identifies the transaction type, processes the transaction, andtransmits the outcome or necessary data to the interested entities orterminals.

Specifically, for the embodiment shown in the figures, the mainprocessor 300 receives the financial transaction data and formats thedata. For example, the data may be converted into a standard ISO 8583format. The main processor 300 then verifies that the transaction is ofa type that can be processed by the electronic financial transactionsystem 120. If the transaction is one that can be processed byelectronic financial transaction system 120, then the main processor 300provides the transaction to the financial data storage system 320. Ifthe transaction is not a transaction that can be processed by theelectronic financial transaction system 120, then the transaction islogged and is returned to the payment administrator terminal 115, thebusiness entity terminal 110, and/or the consumer terminal 105 with amessage stating that it cannot process the transaction.

When the financial data storage system receives the transaction datafrom the main processor 300, the data is provided to the collectorprocessor 350. The collector processor 350 verifies that the transactionis one that can be processed by the financial data storage system 320and verifies that the data is properly formatted. If the transaction isa proper transaction and is intact, then the financial transaction dataproceeds to the rules engine 353. If the transaction is not a propertransaction or if any data is missing or corrupted, then the collectorprocessor 350 returns the data to the main processor 300 for logging thetransaction and returns a denial message to the proper parties.

When the rules engine 353 receives the transaction, the rules engine 353processes the transaction by establishing rules for the engine 353 tofollow. The rules are based on parameters supplied to the rules engine353. The parameters may include transaction parameters establishedbetween the consumer and the business entity; may include businessentity parameters, acquiring FI parameters or issuing FI parametersstored in the business data database; or may include system parametersthat are set by the financial data storage system 320. The rules engine353 first determines the transaction type (e.g., initial transaction,set-up transaction, subsequent transaction or recurring transaction).

Immediate Transaction

If the transaction is an immediate transaction, then the financial datastorage system 320 decrypts any encrypted data (as is discussed below)and returns the transaction to the main processor 300. The electronicfinancial transaction system 120 then processes the transaction similarto when the main processor 300 receives a subsequent transaction(discussed below) from the financial data storage system 320. Oneskilled in the art can draw similarities between the immediatetransaction and the other transactions discussed further below.Therefore, the immediate transaction is not discussed in further detail

Set-Up Transaction

If the transaction is a set-up transaction, then the rules engine 353determines whether the transaction data includes encrypted data. If thetransaction includes encrypted data, then the rules engine 353 providesthe encrypted data identifier to the database engine 365. As describedherein, the rules engine 353 provides only the necessary data to eitherthe database engine 365 or the security processor 355 to perform therequired task. However, the rules engine 353 may provide or transfer alldata to the database engine 365 or the security processor 355 to performthe required task. Variations of either method are also possible.

When the database engine 365 receives the encrypted data identifier, thedatabase engine 365 uses the identifier to access issuer data. Forexample, the issuer data may include the identity of the issuing FIand/or a security or decryption key for decrypting the encrypted data.Of course, other issuer data may be obtained. If the encrypted data isnot recognized then the database engine 365 informs the rules engine353. This results in the rules engine returning the transaction to themain processor 300. The electronic financial transaction system 120 thenlogs the transaction and returns the transaction to the paymentadministrator terminal 115, the business entity terminal 110, and/or theconsumer terminal 105 with a message stating the transaction cannotprocess the transaction.

In another embodiment of the invention, the database engine 365 mayidentify who issued the encrypted financial data, but does not have adecryption key (e.g., another electronic financial transaction system120 has the decryption key). For this embodiment, the transaction datais returned to the main processor 300 via the rules engine 353. The mainprocessor 300 may then forward the financial transaction data to anelectronic financial transaction system 120 that can decrypt the data.In other embodiments of the invention, the encrypted data may have morethan one identifier and, consequently, more than one decryption key.

Once the issuer data (including the decryption key) is obtained, theissuer data is provided to the rules engine 353 and combined with thetransaction data. The rules engine 353 then provides the encrypted dataand the decryption key to the security processor 355. The securityprocessor 355 formats the received data and transmits the data to thedecryption processor 360. The decryption processor 360 uses thedecryption key to decrypt the encrypted data to produce decrypted data(e.g., consumer specific data, financial account data, email address,date of birth, residency, etc.). The decrypted data is then returned tothe rules engine 353 via the security processor 355. The rules engine353 combines the decrypted data with existing transaction data.

The decrypted data include data that is necessary to complete thetransaction and includes data that the consumer does not want to providedirectly to the business entity or payment administrator. For example,the consumer may not want to provide financial account data directly tothe business entity. Rather, the consumer provides the encrypted data tothe business entity (or a payment administrator working on behalf of thebusiness entity) who provides the encrypted data to a transactionfacilitator (e.g., the electronic financial transaction system 120) fordecryption. The transaction facilitator decrypts the data, stores thedata (the encrypted data and/or the decrypted data), assigns a token tothe data, and returns the token and data necessary to complete thetransaction to the business entity. The token may then be used forsubsequent or recurring transactions.

In addition, the encrypted data may include a password used forverifying that the true owner of the encrypted data is providing theencrypted data. For example, the decrypted data may include a decryptedpassword that is compared to a non-encrypted, consumer-providedpassword. If the passwords match, then the electronic financialtransaction system assumes the proper consumer is providing the data.Another security feature of the encrypted data is including a consumeremail address in the encrypted data. After the data is decrypted, anelectronic mail message may be provided to the consumer terminal 105informing the consumer that the encrypted data is being used for atransaction.

Further, the encrypted data may include data for completing thetransaction. For example, the consumer specific data may include amailing address for mailing goods, a place of residence for calculatingtaxes, a citizenship for preventing exportation of various goods, aphone number for voice confirmation, and a date of birth for ageverification, etc. Some of the consumer specific data may be forwardedto the business entity. For example, the mailing address may beforwarded to the business entity thereby eliminating the need for thebusiness entity to obtain the information from the consumer. The date ofbirth may be used by the business entity to verify that the consumer isof legal age to perform the transaction (e.g., is older than twenty-onefor purchasing alcohol). In such a scenario, the electronic financialtransaction system may forward a confirmation to the paymentadministrator that the consumer is a valid age for completing thetransaction. Alternatively, the transaction may include a parameter toreduce the transaction price based on the consumer age (e.g., is olderthan sixty-five). Of course, not all encrypted data may be required forthe pending transaction and other information may be added to theencrypted data. For example, the encrypted data may include a specialmessage (e.g., is a member of an organization) for informing theelectronic financial transaction system 120 that the consumer maypurchase an item not otherwise available to the general public. Foranother example, the encrypted data may include a license number forallowing the consumer to perform a specialized transaction (e.g.,renewing the license) with an agency (e.g., a government agency).

If the consumer provided password matches the decrypted password and theconsumer meets parameters regarding the consumer's demographics (e.g.,is of proper age), then the rules engine 353 proceeds to generate andassign a token to the data. Otherwise, the rules engine returns thetransaction to the main processor 300 for logging the transaction andreturning the transaction to the proper parties stating it cannotprocess the transaction. As used herein, the token signifies oridentifies the transaction data. The token may be unique by itself, ormay be used in combination with another piece of data. For example, theembodiment described herein uses a generated number and the encrypteddata identifier to create a token for identifying the transaction data.

The decrypted financial data further include currency exchange networkdata. These data provide the identity of the issuing FI to theelectronic financial transaction system. The currency exchange networkdata include a routing/transit number of the issuing FI 130, an accountnumber or other information identifying the account within the issuingFI 130, the card issuer, an expiration date of the card, and a servicecode identifying the type of card. Of course, the currency exchangenetwork data may include other data and not all data is required forother embodiments.

For some embodiments, the transaction data does not include encrypteddata. For example, the consumer may interact with a trusted paymentadministrator who submits the unencrypted transaction data to theelectronic financial transaction system 120. For this type oftransaction, the financial data storage system does not need to decryptany data. However, similar to above, a token is assigned to thetransaction data. This token may then be provided to a business entity(or a payment administrator acting on behalf of the business entity) aspart of a subsequent or recurring transaction.

After generating a token, the rules engine 353 provides the transactiondata to the database engine 365. The database engine 365 stores thetransaction data (including the encrypted data identifier) and the tokenin the transaction data storage database 370. Of course, not all of thetransaction data is required to be stored in the transaction datastorage database 370. For example, it is not necessary to store both thedecrypted data and the encrypted data.

After the transaction data is stored, the rules engine 353 transmits thetransaction data, the decrypted financial data and the token to the mainprocessor 300. Of course, the main processor 300 may retain some of thetransaction data, and therefore, all data need not be provided a secondtime.

The transaction data (including the decrypted transaction data) and thetoken are provided from the main processor 300 to the primary messagecontrol processor 310. In other embodiments, not all of the transactiondata need be transferred to the primary message control processor 310.However, for the embodiment described herein, when data are exchangedbetween processors 300, 305 and 310, all data are exchanged.

The primary message control 310 analyzes the data within thetransaction, identifies that the transaction is a set-up transaction,and creates a request to the issuing FI 130. For example, the requestmay include an inquiry querying whether the consumer's account ispresent at the issuing FI 130. In addition, the request may inquire asto whether sufficient funds are present within the account. Once therequest is created, the primary message control 310 determines how thetransaction should be routed within the current exchange network 125(e.g., what is the best route to the issuing FI). The primary messagecontrol 310 returns the request, the route, the transaction data, andthe token to the main processor 300. The main processor 300 forwards allof the data to the currency exchange communications processor 305.

The currency exchange communications processor 305 then submits therequest and the route to the currency exchange network 125. The requestis transmitted to the issuing FI 130 as is known within the art. Uponreceiving the request, the issuing FI 130 prepares a response for therequest (e.g., whether the consumer's account is a valid and openaccount with sufficient funds to satisfy the transaction). The responseor authorization decision of the issuing FI 130 is transmitted back tothe currency exchange communications processor 305 via the currencyexchange network 125. The currency exchange communications processor 305then returns the response to the main processor 300. The main processor300 analyzes the result and informs the necessary parties (e.g., thepayment administrator terminal 115, the business entity terminal 110and/or the consumer terminal 105) of the result. In addition, the tokenis returned to the payment administrator terminal 115 for subsequent orrecurring transactions. Enough information is sent to each party toallow each party to reconcile its records. For example, the paymentadministrator terminal 115 may receive data including the encrypted-dataidentifier, the trace number, the token, the submitted date, thesubmitted time, the parameters of the transaction, etc. Of course,additional information may be returned to the payment administratorterminal 115 including a response code (e.g., whether the consumerexists or whether the transaction took place), consumer specific dataobtained from the encrypted financial information (e.g., the mailingaddress for sending goods, whether the consumer is of age to perform thetransaction, etc.), etc. However, not all transaction data is providedto each party. For example, the payment administrator terminal 115 doesnot receive the financial account data.

Once the payment administrator terminal 115 receives the response(including the token), then the data may be forwarded to the businessentity for resubmission by the business entity or may be retained by thepayment administrator terminal 115. If the issuing FI 130 returns adenial or negative confirmation, then the denial is also returned to therules engine 353. The rules engine 353 receives the denial and logicallyerases the stored transaction data and the corresponding token withinthe transaction data storage database 370. After the result is sent, thelog 315 is updated for record and billing purposes.

For the embodiment shown in the figures, the transaction data isprovided from the consumer terminal 105 or the business entity terminal110 to the payment administrator, which is acting on behalf of thebusiness entity. However other embodiments are envisioned. For example,the consumer may register financial information directly with a paymentadministrator acting on behalf of the consumer. For example, theconsumer may directly contact the payment administrator and provideset-up transaction data to the payment administrator. The paymentadministrator provides the transaction data to the electronic financialtransaction system 120 and receives a token in response thereto. Thetoken is then forwarded to the consumer. At a later time, the consumersubmits the token to a business entity (or a payment administratoracting on behalf of the business entity), which provides the token andsubsequent transaction data (discussed below) to the electronicfinancial transaction system 120. For a specific example, the consumermay telephone the payment administrator and register a credit cardnumber and transaction parameters with the administrator. The telephonecall results in the consumer receiving a token assigned to the creditcard number. The token may then be submitted to a business entity inplace of the credit card number for performing a subsequent transaction.This provides extra security to the consumer that the credit card willnot be compromised. The parameters assigned to the token may specifythat the token only be used for five transactions up to a specifieddollar amount. In other words, the electronic financial transactionsystem 120 is able to register credit card details and be able toinitiate credit card purchases based on the registered details. Othertypes of transactions and variations of the system are possible

Subsequent and Recurring Transactions

For the embodiment shown in the drawings, the payment administratorterminal 115, which is acting on behalf of the business entity, submitsthe earlier received token when an agreed upon condition is fulfilledtriggering the submission. For example, in a subsequent transaction, thecondition may be that the business entity can only request for transferof funds when the transacted goods are shipped. As another example, in arecurring transaction, the condition may be the passage of a period oftime (e.g., a monthly payment is due). When submitting the subsequent orrecurring transaction, the payment administrator transmits the token andsubsequent or recurring transaction data to the electronic financialtransaction system 120. The token informs the electronic financialtransaction system 120 that set-up transaction data necessary tocomplete the transaction is stored at the transaction data storagedatabase 370. The subsequent or recurring transaction data includedetails relating to the amount of the subsequent or recurringtransaction, any data not stored at the transaction data storagedatabase but is necessary for the electronic financial transactionsystem 120 to complete the transaction, and data for later reconcilingthe transaction at the payment administrator (e.g., a trace number, atransaction date, a transaction time, etc.). In general terms, theelectronic financial transaction system 120 obtains the previouslystored transaction data associated with the token, and implements thetransaction with at least a portion of the stored transaction data.

During a subsequent or recurring transaction, the subsequent orrecurring transaction data and the token are provided to the rulesengine 353 similar to the set-up transaction. When the rules engine 353receives the token, it recognizes that the transaction is a subsequentor recurring transaction. The rules engine 353 provides the token to thedatabase engine 365, which obtains the previously provided set-uptransaction data. If the stored transaction data includes encrypted dataand no corresponding decrypted data was stored, then the encrypted datais decrypted as was discussed with the set-up transaction. In addition,the database engine 365 updates the stored transaction data to signifythat the subsequent or recurring transaction is taking place. Forexample, if the transaction is a subsequent transaction, then thetransaction data storage database 370 is updated to signify that thesubsequent transaction has taken place. Similarly, if the transaction isa recurring transaction, then the transaction data storage database 370is updated to signify that an additional recurring transaction has takenplace.

Upon receiving the set-up transaction data, the rules engine 353 maycompare some of the previously provided set-up transaction data with thenewly provided transaction data. For example, the set-up transaction mayinclude an amount parameter which is compared to the amount requested aspart of the subsequent or recurring transaction. In addition, the rulesengine 353 verifies that the transaction has not been completed (e.g.,the subsequent transaction has not previously fulfilled). If the rulesengine 353 determines an error has occurred, then appropriate partiesare notified and the transaction is logged. For example, if a businessentity is wrongfully requesting the electronic financial transactionsystem 120 to perform a subsequent transaction, then an electronic mailmessage is sent to the email address listed in the encrypted data (e.g.,the presumed consumer email address).

Once the rules engine 353 receives the earlier provided set-uptransaction data (including the decrypted data), the data is returned tothe main processor 300 and is combined with the subsequent or recurringtransaction data. Of course, any redundant data may be removed. Thecomplete transaction data is then provided to the primary messagecontrol 310. The primary message control 310 analyzes the transactiondata, identifies that the transaction is a subsequent or recurringtransaction, and creates a request to the issuing FI. The request iscreated similar to the set-up request. However, the request includes anadditional request for the issuing FI to debit or credit funds in theconsumer's account. Once the request is created, the primary messagecontrol 310 creates a route for transmitting the request to the currencyexchange communications processor 305.

The request is then provided to the currency exchange communicationsprocessor 305 via the main processor 300. The currency exchangecommunications processor 305 submits the request to the currencyexchange network 125 and the request is transmitted to the issuing FI130 as is known in the art.

Upon receiving the request, the issuing FI 130 verifies the existence ofthe consumer account, and debits or credits the account. A response iscreated by the issuing FI 130 that is returned to the currency exchangecommunications processor 305 via the currency exchange network 125. Uponreceipt, the response is forwarded to the main processor 300 foranalysis. If the removal of the funds is successful, then the mainprocessor 300 informs the parties of the success, and logs thetransaction for later settlement of funds and for billing purposes. Atthe end of an accounting period (e.g., at the end of each day), thelogged transactions are netted and consolidated, and funds aretransferred to and from the logged FIs as is known in the art.

If the removal of funds was unsuccessful (e.g., the request results in anon-sufficient funds result), then the proper parties are informed andthe transaction is logged for billing purposes. In addition, thetransaction data and the denial are provided to the financial datastorage system 320 for updating the transaction data storage database370. For example, if the transaction is a subsequent transaction and theconsumer's account had insufficient funds, then the token stored in thetransaction data storage database 370 is reactivated. The consumer maythen add funds to the consumer's account and have the transactionresubmitted. Similarly, if the transaction is a recurring transactionwith a limited number of recurring payments, then the stored transactiondata may be updated to reflect a non-completed transaction.

In another embodiment of the invention, if the electronic financialtransaction system 120 receives the response stating the removal offunds was successful, then the electronic financial transaction system120 sends a separate request to the acquiring FI 135. The separaterequest asks the acquiring FI to add funds to the business entity'saccount. For this embodiment, the data relating to the business entity'saccount was provided either as part of the set-up transaction dataand/or the subsequent or recurring transaction data.

As can be seen from the above, the invention provides a useful systemand method of performing a financial transaction between a first entityand a second entity utilizing a third entity as a transactionfacilitator. The system and method of the invention are useful in thatthey facilitate transactions between parties in a safe and secure mannerwithout allowing the confidential information of one of the parties tobe disclosed to another of the parties. As described herein, the systemand method of the invention are useful to facilitate delayed andrecurring payment transactions, to verify the consumer meets apredetermined requirement (e.g., an age requirement), and/or todetermine the consumer's legal place of domicile. Various features andadvantages of the invention are set forth in the following claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving, from a communications network by a computer at a transactionfacilitator, a request for a token from a consumer computer, the requestincluding: encrypted data, parameters associated with a financialtransaction, comprising at least one of an identity of a business entitydifferent from the transaction facilitator, a transaction date, or atransaction time, and transaction data associated with the consumer,comprising at least one identifier for the encrypted data; generating,by the computer at the transaction facilitator, the token identifyingthe transaction data, using the at least one identifier for theencrypted data; storing, by the computer at the transaction facilitator,the transaction data and the token, wherein storing comprisesassociating the transaction data with the token; providing, by thecomputer at the transaction facilitator, the token to the consumercomputer; receiving, by the computer at the transaction facilitator,from the consumer computer, the token previously-generated by thetransaction facilitator to initiate a financial transaction between theconsumer and the business entity; obtaining, at the transactionfacilitator, the stored transaction data identified by the token;verifying the transaction data meets a predetermined requirement; andinitiating, by the computer at the transaction facilitator, thefinancial transaction between the consumer and the business entity andwithholding at least a portion of the transaction data from the businessentity.
 2. The method of claim 1, the request for the token comprisingat least one consumer supplied identifier for the encrypted data.
 3. Themethod of claim 1, the consumer supplied encrypted data comprisingencrypted financial account data.
 4. The method of claim 3, the requestfor the token comprising a consumer supplied identifier for theencrypted financial account data.
 5. The method of claim 3, the consumersupplied encrypted financial account data comprising an encryptedrouting number for an issuing financial institution.
 6. The method ofclaim 3, the consumer supplied encrypted financial account datacomprising an encrypted account number at an issuing financialinstitution.
 7. The method of claim 1, the consumer supplied encrypteddata comprising encrypted consumer specific data relating to theconsumer.
 8. The method of claim 7, the request for the token comprisinga consumer supplied identifier for the encrypted consumer specific data.9. The method of claim 7, the encrypted consumer specific datacomprising an encrypted date-of-birth of the consumer.
 10. The method ofclaim 7, the consumer specific data comprising an encrypted electronicmail address of the consumer.
 11. The method of claim 7, the consumerspecific data comprising an encrypted mailing address of the consumer.12. The method of claim 7, the consumer specific data comprising anencrypted state of residency of the consumer.
 13. The method of claim 1,the consumer supplied encrypted data comprising a consumer suppliedencrypted password.